漏报溯源通常有哪些环节

漏报溯源通常有以下这些环节：

• 单点的检测手段不足是绝大多数人都会想到的，可能是检测规则写得不够好，对某些情况没有考虑到，补充相关场景的检测规则即可。例如只做了rootkit检测，而没有考虑诸如“不利用任何第三方可执行文件实现的反弹shell”就属于这一类情况。

• 单点的检测深度如果没有问题，那么可能的原因是单维度的数据不足以捕捉事件，或者单维度数据不足以精确剔除误报，这个时候就要引入其他维度的数据作对比，典型的例子比如SQL注入，在CGI层面要对抗HTTP编码问题，单维度的WAF数据还不够，可能需要从SQL层引入第二层检测，两个维度叠加后出结果。更常见的webshell则有很多维度。

• 在大型互联网中，单点的深度和检测维度都没有问题，而是出问题的机器上还没安装和运行相关的检测产品，全网的部署覆盖率才50%，剩下的50%在这几个维度是裸奔，所以被人捅了马蜂窝。这个问题其实也无解，只有加速提升覆盖率。反过来说，单点的检测方案再美好，因为影响了性能和可用性推广不了，最后都等于没有。所以把安全的功能和检测能力放在第一位的方案往往不是最优解。

• 进程挂了，模块挂了，数据同步漏了。最后的结果就是出问题时正好漏过了，一方面可能是因为产品本身的健壮性比较差，另一方面可能是设计不够好，体积臃肿，垃圾数据大堆，真正的数据利用率很低。

• 覆盖率100%，但是数据质量不高，导致的误报很多，有价值的信息也被淹没了。质量不高有两层含义：第一层数据源跟检测目标的相关性不强，传统的SOC里采集了大量的数据，但很多信息不是安全强相关，也不足以判断到底发生了什么，这种数据就没什么用。比如防火墙的日志里一大堆数据包分片的告警，在海量的环境下纯属垃圾信息。第二层含义是模糊告警太多，很多中低风险疑似触发安全策略的告警，需要通过手工做大量验证，整体上ROI很低。人有习惯效应，告警刷屏多了又不是严重告警，人会自动“选择性忽略”，这样还不如没有。